What effect would this have on other toolchains? For instance, you can add picolibc support to the arm embedded toolkit by downloading the picolibc overlay, you can build native a crosstool-ng toolchain which can have picolibc support included, or you could be using the native Debian arm-none-eabi toolchain, which has picolibc support.

What effect would this have on other toolchains?

None.
This only sets the setting to y when Zephyr SDK is used.
When another toolchain is used, then the setting inside the Zephyr repo is used.

oh. How does this detect whether the user is building the picolibc module? Because you could be using the zephyr toolchain but not using the picolibc bits it provides, and that wouldn't work for C++.

This doesn't allow Zephyr to restrict picolibc usage for boards that don't work, even if picolibc works for the target architecture (like qemu_x86_tiny). Perhaps this should use a new variable, TOOLCHAIN_PICOLIBC_SUPPORTED, and that variable could be used in the computation of PICOLIBC_SUPPORTED?

This doesn't allow Zephyr to restrict picolibc usage for boards that don't work, even if picolibc works for the target architecture (like qemu_x86_tiny).

Correct, so if we do have such boards then we need to consider how to handle them.

What is the reason that a given board would impact the use of picolibc ?
Especially as from your description, the architecture itself is supported.
(and is it really the board, and not the SoC which are restricting picolibc ?)

Do you have some concrete examples ?

Probably this is something which should be handle directly at the board, and the board Kconfig in fact has a possibility to default the TOOLCHAIN_PICOLIBC_SUPPORTED to n if this is needed.